Methods and systems for regulating service layer agreements for multiple cloud service requests

ABSTRACT

Methods and systems are disclosed for providing cloud services to multiple customers in a cloud. One embodiment includes receiving a number of requests for the cloud services from the multiple customers simultaneously or substantially simultaneously; prioritizing the requests based on a probability distribution of actually deploying a service, a budget of the customers, and an expected demand of the requested service based on the probability distribution; generating a number of cloud configurations along with a number of Service Level Agreements (SLAs) for the customers based on prioritization of the requests, a class &amp; past behavior of the customers, and a current demand of the cloud services, the SLAs of the customers include differentiated price offering; recommending the cloud configurations and the SLAs to the customers; allowing the customers to negotiate terms of the SLAs; and providing the cloud services based on the negotiated SLAs to the customers.

TECHNICAL FIELD

The presently disclosed embodiments relate to networks, and moreparticularly, to methods and systems for providing cloud services.

BACKGROUND

With the advent of computing clouds, there has been a surge incloud-based services. Cloud-based services provide service users withon-demand access to virtualized resources for service execution,including networks, servers, applications, data storage, and servicesrunning on a platform. In recent years, there has been a significantincrease in the scale of services hosted over the cloud. In addition,given the wide gamut of service users ranging from business users, e.g.,business analysts, to small and medium business (SMB) customers, make itadvantageous, and in some cases, imperative to present the services inthe marketplace in an easy-to-use manner. Unfortunately, conventionalmethodologies for presenting cloud services require specific cloudconfiguration details from users, e.g., SW platform requirements, numberof processors, the type and number of virtual machines (VMs), amount ofstorage, and so forth.

Conventional interfaces or virtualization engines, e.g., Amazon EC2,Rackspace, Microsoft Azure, ACS AMP 3.0, IBM TSAM, Sun Virtualbox, andso forth, present cloud-based services as infrastructure solutions whereusers need to provide detailed cloud configuration inputs. Usually, inthe SMB marketplace where it may be advantageous for many cloud vendors,such as Xerox and ACS Cloud, to extend their cloud services business,detailed cloud configuration information may be unknown to the users,especially to non-IT experts. Hence, users may erroneously requestinefficient configurations of services, either overprovisioning orunder-provisioning their services. In at least some cases ofoverprovisioning, more resources are configured than are actuallyneeded, which may lead to resource over-use, causing the energy usageand budget for the service to be higher than necessary. On the otherhand, at least some cases of under-provisioning, fewer resources may berequested than required to maintain the desired performance demandsresulting in a failure to satisfy such demands.

It may therefore be advantageous to provide enhanced methods or systemsfor recommending and regulating cloud configuration and Service LevelAgreement (SLA) of applications requested by multiple customers in thecloud service marketplace.

SUMMARY

The presently disclosed embodiments provide methods and systems forproviding one or more cloud services to a number of customers in acomputing cloud. The presently disclosed embodiments provide a regulatedrecommendation system whereby a differentiated pricing basedgame-theoretic approach can be used to set different pricing ranges fordifferent services depending upon customer type as well as an expecteddemand for resources. Embodiments of the disclosed methods can includereceiving a number of requests for the one or more cloud services fromcustomers simultaneously, substantially simultaneously or generally atthe same or related times. The customers can be categorized into one ormore classes, such as, but not limited to, a gold class, a silver class,a bronze class. The method can further include prioritizing the requestsbased on at least one of a probability distribution of actuallydeploying a requested service, a budget of each of the customers, and anexpected demand of the requested service based on the probabilitydistribution. The method can also include generating a number of cloudconfigurations along with a number of Service Level Agreements (SLAs)for each of the customers based on at least one of the prioritization ofthe requests, a class of each of the customers, past behavior of each ofthe customers, and a current demand of the cloud services in thecomputing cloud. The SLAs of the customers can include differentiatedprice offering. In some embodiments, the method can include recommendingthe generated cloud configurations and the SLAs to each of thecustomers. Further, price offering in each of the SLAs can be providedas a range including an upper limit and a lower limit for deploying oneor more cloud services. In some embodiments, the method also includesallowing each of the customers to negotiate terms of its associated SLAand providing one or more cloud services based on the negotiated SLAs tothe customers. The SLA for each of the customers is generated, such thatrevenue of a service provider is enhanced, increased or maximized, whileenhancing, improving or ensuring customer satisfaction and/orquality-of-recommendation.

Another embodiment of the present disclosure provides a system forproviding one or more cloud services to a plurality of customers in acomputing cloud. The system can include a service level agreementregulation (SLA) system at a service layer of the computing cloud. TheSLA regulation system can include a request processor configured toreceive a number of requests for requesting the one or more cloudservices from the multiple customers simultaneously, substantiallysimultaneously or generally at the same or related times. The customerscan be categorized into one or more classes. The request processor canbe further configured to process the requests based on at least one of aprobability distribution of actually deploying a requested service, abudget of each of the customers, and an expected demand of the requestedservice based on the probability distribution. The SLA regulation systemcan also include a cloud configuration generator configured to generatea number of cloud configurations along with a number of service levelagreements (SLAs) for each of the customers based on at least one of theprioritization of the requests, a class of each customer, past behaviorof each of the customers, and a current demand of the cloud services inthe computing cloud. In some embodiments, the SLAs of the customersinclude differentiated price offering. This SLA regulation system canfurther include a recommender system configured to recommend thegenerated cloud configurations and the SLAs through a number of outputinterfaces. The price offering in the SLAs can be provided as a rangeincluding an upper limit and a lower limit for deploying the one or morecloud services. The system can further include an SLA negotiatorconfigured to allow each of the customers to negotiate terms of itsassociated SLA. The computing cloud provides the one or more cloudservices based on the negotiated SLAs to the customers. The SLA for eachof the customers is generated, such that revenue of a service provideris enhanced, increased or maximized, while enhancing, improving orensuring customer satisfaction and/or quality-of-recommendation.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary cloud architecture, in accordance withvarious embodiments of the present disclosure.

FIG. 2 illustrates structural components of the SLA regulation system ofFIG. 1, in accordance with an embodiment of the present disclosure.

FIG. 3 shows an exemplary screenshot for configuring the SLA regulationsystem, in accordance with an embodiment of the present disclosure.

FIG. 4 illustrates an exemplary embodiment of the SLA regulation systemwhen receiving one or more inputs from multiple customers.

FIG. 5 illustrates an exemplary embodiment of a system architecture forthe SLA regulation system for handling multiple requests.

FIG. 6 illustrates an exemplary screenshot of the SLA regulation system.

FIG. 7 is a flowchart illustrating various steps of a method 700 forregulating service level agreements (SLAs) by the SLA regulation system108, in accordance with an embodiment of the present disclosure.

FIGS. 8A-8C illustrates a method for providing one or more cloudservices to a number of customers in the computing cloud, in accordancewith various embodiments of the present disclosure.

DETAILED DESCRIPTION

The following detailed description is made with reference to thefigures. Exemplary, and in some cases preferred embodiments aredescribed to illustrate the disclosure, not to limit its scope, which isdefined by the claims. Those of ordinary skill in the art will recognizea number of equivalent variations in the description that follows.

DEFINITIONS

In various embodiments, definitions of one or more terms that will beused in the document are described below. The term ‘energy rating’ candefine the relative energy consumption by a cloud-based service withrespect to all other services in a cloud. The term ‘green operation’ canindicate the effect of the carbon footprint on the environment. Theenergy rating can, therefore be inversely related to the greenoperation, e.g., the lower the energy consumption, the greener theoperation. Quality of Service (QoS) can include various factors,including, but not limited to, response time and throughput fordelivering the cloud services successfully. Service Level Agreement(SLA) can refers to a contract with QoS guarantees as required by thecloud customer.

Overview

The present disclosure describes methods and systems for providing oneor more cloud services to a number of customers in a cloud. The presentdisclosure introduces a regulated recommendation system, where adifferentiated pricing based game-theoretic approach may be used to setdifferent pricing range to different services, which are potentiallycontending for same set of available resources, depending on customertypes, behavior, and expected demand of resources. The differentiatedpricing may prioritize the service requests and then accordingly searchfor best configuration. The recommendation system may use the inherentprobabilistic prioritization incurred by the pricing mechanism to planfor resources accordingly.

Overall Exemplary Cloud Architecture

Energy consumption to run cloud-based services is derived mainly fromthe underlying infrastructure, but there are different componentscontributing to the energy demand of the overall cloud. As discussedabove, those components can be categorized as contributing toplatform-specific energy demand and/or service-specific energy demand.Unlike the infrastructure-specific demand and the platform-specificdemand, the service-specific energy demand, however, can be relaxed byallowing negotiations of SLAs on Quality of Service (QoS) parameters.Thus, service-specific energy reduction can provide higher flexibilityby enabling a reduction in performance (i.e., by relaxing the QoSparameters) and hence providing greater opportunity for energy savings.The present disclosure intends to address the gap by focusing on theservice layer and thereby providing an enhanced SLA regulation system.

FIG. 1 illustrates an exemplary cloud architecture 100 (which may alsobe referred to as cloud 100), in accordance with various embodiments ofthe present disclosure. The cloud 100 may be a cloud service for use ina market place. In some embodiments, the cloud 100 may include aninfrastructure layer 102, a platform layer 104, also known asmiddleware/virtualization layer, a service layer 106, a service levelagreement (SLA) regulation system 108, a number of customers 110A-N, anda service marketplace portal 112. Each of the shown components maycommunicate with the others using conventional network protocols and/orany other known, related art or later developed method(s) or system(s)and will be described in detail in the following sections.

The infrastructure layer 102 may include various kinds of computingequipment, such as servers, switches, databases, and the like. Thecomputing equipment can support operations and host the cloud services.In some embodiments, a service monitoring and management system, and aprovisioning and management system (not shown) may be implemented at theinfrastructure layer 102. These systems may determine power profiles ofthe equipment at the underlying infrastructure layer 102 when requiredor otherwise advantageous. The platform layer 104 offers platforms interms of operating systems, Windows Azure, for example, which runs overthe underlying infrastructure. In some implementations, at the platformlayer 104, virtual machines are hosted on the actual machines orservers. Finally, at the service layer 106, various services are hostedthat are used by the customers 110A-N.

Cloud-based services (or cloud services) are traditionally presented tothe customers 110A-N in a way where the customers 110A-N need to inputspecific cloud configuration details, such as, hardware (HW), software(SW), platform, and resource requirements. Such information is usuallyunknown to business users, especially in an SMB marketplace. Hence,services are either over-provisioned, leading to excess energy usage, orunder-provisioned, affecting performance. In an exemplary scenario, ifmultiple requests are received from multiple customers 110A-N, thenrecommending a configuration and allocating resources corresponding tothese requests may be a challenging task. The customers 110A-N arespatially (i.e., geographically) distributed across the world. Inaddition, for a set of requests, recommending configuration based onconventional methods may lead to over-estimation or under-estimation.Over-estimation means planning to map resources, which may not beactually available, and under-estimation refers to not planning to mapresources, which may be actually available. The over-estimation mayoccur because not all of the available resources may be planned to hosteach individual service request. The under-estimation can occur if thebest-effort approach is extended to incorporate all the requestssimultaneously or substantially simultaneously, since in the marketplace it is highly likely that not all services would actually besubmitted for deployment by the customers 110A-N. It is thereforenecessary to have some level of regulation of the recommendations basedon type (class) and behavior of the customers 110A-N.

The SLA regulation system 108 of one embodiment relieves the customers110A-N from the time and effort of entering all the configurationdetails for requesting various cloud-based services and also regulatesthe SLA prior to recommending to avoid over-estimation andunder-estimation if multiple requests are received from the customers110A-N. The SLA regulation system 108 is configured to regulate cloudconfiguration and corresponding SLA for multiple requests (or customers110A-N) generated based on a few high-level details received from thecustomers 110A-N, past behavior of the customers 110A-N and currentdemand of the resources in the cloud 100. The high-level details mayinclude, but are not limited to, performance level, location, GreenPoint, budget, and so forth. The budget may define the cost, which thecustomer is willing to pay for accessing or deploying the requestedservices. In some embodiments, each of the customers 110A-N can selectthe high-level parameters from a value set associated with one or morehigh-level parameter fields through the service marketplace portal 112and various service offerings can be provided to the one or morecustomers 110A-N. The one or more high-level parameter fields may referto one or more data fields in which the customers 110A-N may enter thehigh-level parameters.

The SLA regulation system 108 may receive a number of requests for oneor more cloud services from the customers 110A-N simultaneously, orsubstantially simultaneously. The customers 110A-N may be categorizedinto one or more classes depending on one or more predefined criteria.An example of the predefined criteria may include classifying thecustomers 110A-N into classes, such as a gold class, a silver class, abronze class, and so forth depending on frequency of requests receivedfrom the customers 110A-N over a period of time. Further, the customers110A-N may be classified into multiple classes based on an initialregistration process. For example, the customers 110A-N may registerthemselves with a service provider of cloud services before requestingor accessing the cloud services. In an embodiment, the SLA regulationsystem 108 is configured to assign a priority to the one or moreservices, such that a service with highest probability of acceptance isgiven higher preference to get the resources.

The SLA regulation system 108 can be configured to process the requestsbased on at least one of a probability distribution of actuallydeploying a requested service, a budget of the customer(s) 110A-N, andan expected demand of the requested service based on the probabilitydistribution. The probability of deployment refers to a measure (orpercentage) of actually deploying the requested services by a customerof the customers 110A-N. For example, a customer may not deploy a SLAafter allocation in which case, the probability of deployment is low.The SLA regulation system 108 may also prioritize the multiple requestsin a queue based on a descending order of the probability of deploymentof the requested one or more cloud services and the price offering. Theprice offering defines a sample price, which may be offered by the SLAregulation system as part of SLA for providing the requested services.In an embodiment, the SLA regulation system 108 may provide thecustomers 110A-N with the price offering after receiving the requestsfor one or more cloud services. There may be a number of resourcesavailable in the computing cloud 100 for deployment of cloud services.The resources can be servers, computers, virtual machines, softwareapplications, and so forth. The SLA regulation system 108, whilecalculating the price offering or generating the cloud configuration orSLA, may reduce, for each of the requests, an availability ofresource(s) based on an expected demand of the one or more cloudservices by previous requests in the queue.

The SLA regulation system 108 may also generate a number of cloudconfigurations along with a Service Level Agreements (SLAs) for each ofthe customers 110A-N based on at least one of the prioritization of therequests, a class of each of the customers 110A-N, past behavior of eachof the customers 110A-N, and a current demand of the cloud services inthe computing cloud. A separate cloud configuration and SLA may begenerated for each of the customers 110A-N. The SLA regulation system108 may maintain details about each customer's 110A-N past behavior,resources, each customer's 110A-N basic information, and so forth. TheSLAs of the multiple customers 110A-N may include different priceoffering is for the one or more cloud services. Further, the priceoffering in each of the SLAs may be provided as a range, including anupper limit and a lower limit for deploying the one or more cloudservices. For example, the price offering for deploying a cloud servicemay be $100-$300. The SLA regulation system is also configured todetermine, for each of the requests, a probability of deployment of theone or more services corresponding to the price offering. In anembodiment, the SLA regulation system 108 may determine a price offeringfor each of the multiple requests based on a posterior distribution ofdemand after observing the current demand of services by the customers110A-N, and the prior distribution of resources required for deployingthe requested one or more services to the customers 110A-N.

In an embodiment, the SLA regulation system 108 can search for anenhanced, improved, and is some case an optimal or best cloudconfiguration for each of the requests (or customers 110A-N) based on atleast one of the prioritization of requests, a class of each of thecustomers, past behavior of the customers 110A-N, and a current demandof the one or more cloud services in the cloud 100. For example, acustomer 110A of a gold class may be offered a lower price for aparticular cloud service as compared to another customer 110C of abronze class for the same cloud service. In an exemplary scenario, acustomer 1108 having a high probability of deployment in the past may beoffered maximum resources for deploying a service than another customer110C having a low probability of deployment. Further, the SLA regulationsystem 108 may generate the cloud configuration(s) along with the SLA(s)by estimating at least one of a budget, a Green Point, a performancelevel, and energy consumption for each possible cloud configurationbased on the received high-level parameters.

In one embodiment, the SLA regulation system 108 may recommend thegenerated cloud configurations and the associated SLAs through a numberof output interfaces (see FIG. 2) to multiple customers 110A-N. Thecloud configurations and the SLAs may be recommended to each of thecustomers 110A-N based on an expected availability of resources requiredfor deploying the requested one or more cloud services in the computingcloud 100.

Further, the SLA regulation system 108 can be configured to allow eachof the customers 110A-N to negotiate terms of its associated SLA whenthe customer 110 (hereinafter, customer 110 refers to a single customer)is not satisfied with the recommended SLA. Further, the SLA regulationsystem 108 may receive one or more new inputs from the customer 110 tofine tune or modify the previously recommended SLA, or generate a newSLA based on new inputs until the customer 110 is satisfied with theSLA. In some embodiments, each of the customers 110A-N can negotiate theterms of the SLA based on a trade-off between the one or more high-levelparameters at a service layer of the cloud 100. Further, the SLAregulation system 108 may change the terms of the SLA based on theservice level SLA negotiation or inputs received from the customer 110(or customers 110A-N). Further, the SLA regulation system 108 maygenerate the multiple SLAs for each of the customers 110A-N, such thatrevenue of a service provider is enhanced, increased, or in some cases,maximized, while enhancing, improving or even ensuring customersatisfaction and/or quality-of-recommendation. This procedure enable thecustomers 110A-N to finalize an SLA for deploying the requested cloudservices.

Thereafter, the cloud 100 may provide the one or more cloud servicesbased on the negotiated or finalized SLAs to each of the customers110A-N. Further, the price offering in the generated SLAs (orrecommended SLAs) is such that a potential revenue for the serviceprovider is enhanced, increased, or even maximized, while taking intoaccount the probability distribution of the customer actually deployingthe services with one or more of the high-level parameters.

FIG. 2 illustrates structural components of the SLA regulation system108 of FIG. 1, in accordance with an embodiment of the presentdisclosure. The SLA regulation system 108 may include a number ofservice input interfaces 202A-N, a request processor 204, a cloudconfiguration generator 206, a differentiated pricing module 208, arecommender system 210, a number of output interfaces 212A-N, a servicelevel agreement (SLA) negotiator 214 and a database 216. The serviceinput interfaces 202A-N may include one or more data fields to allow thecustomers 110A-N to enter high-level parameters. As discussed withreference to FIG. 1, the customers 110A-N may request one or more cloudservices by entering one or more high-level details in the service inputinterfaces 202A-N. The high-level parameters may include at least oneof, but not limited to, a performance level, a Green Point, a budget,and a location. The service input interfaces 202A-N may also allow thecustomers 110A-N to enter one or more service inputs. The service inputsmay include at least one of a service name and one or more servicespecific parameters. Each of the customers 110A-N may select thehigh-level parameters from a value set associated with one or morehigh-level parameter fields of each of the service input interfaces202A-N.

The request processor 204 is configured to receive these one or morerequests from the customers 110A-N simultaneously or substantiallysimultaneously. Further, the request processor 204 may process theserequests based on at least one of a probability distribution of actuallydeploying a requested service, a budget of each of the customers 110A-N,and an expected demand of the requested service based on the probabilitydistribution. A budget of a customer 110 may be received as an input. Insome embodiments, the budget of the customer 110 may be estimated basedon the past behavior of the customer 110. The probability distributionrefers to the probability of actually deploying the requested service bythe customers 110A-N in past similar scenarios, on allocation ofresources by the cloud service provider. For example, a customer 110A ofthe customers 110A-N may request a service that requires ten servers anda service that requires eight servers, even though in the past thecustomer 110 has always deployed a service requiring eight servers.Therefore, the probability of a service requested by the customer 110Arequiring eight servers is more than the service requiring ten servers.The request processor 204 is further configured to determine, for eachof the requests, a probability of deployment of the one or more servicescorresponding to the price offering. This means that the requestprocessor 204 may determine the probability of deploying a service at anoffered price. Based on this probability of deployment for each of therequested services, a probability distribution may be maintained by theSLA regulation system 108 (or the request processor 204) for all of thecustomers 110 A-N.

The request processor 204 is further configured to prioritize therequests in a queue based on a descending order of the probability ofthe requested one or more cloud services and the price offering (offeredby the SLA regulation system 108). The request processor 204 may arrangethe requests in descending order of probability of the requested one ormore cloud services and the price offering in the queue. The requestprocessor 204 is further configured to reduce, for each of the requests,an availability of resources based on an expected demand of the one ormore cloud services by previous requests in the queue. This means that,the request processor 204 may reduce the number of available resourcesas one or more requests of the queue may be processed based on thedemand of the cloud services.

The cloud configuration generator 206 is configured to generate a cloudconfiguration along with a service level agreement (SLA) for each of thecustomers 110A-N based on at least one of the prioritization of therequests, a class of each of the customers 110A-N, past behavior of eachof the customers 110A-N, and a current demand of the cloud services inthe cloud 100. The SLA regulation system 108 may include a database 216to store details about class associated with each of the customers110A-N, past behavior of the customers 110A-N, and probabilitydeployment distribution for the various cloud services for each of thecustomers 110A-N. The SLAs for each of the customers 110A-N may begenerated such that revenue of a service provider is enhanced,improvised or even maximized, while enhancing, improving or evenensuring customer satisfaction and/or quality-of-recommendation. In anembodiment, the recommender system 210 may generate the cloudconfigurations and SLAs for the customers 110A-N. Further, the SLAs ofthe customers 110A-N may include a differentiated price offering for theone or more cloud services for different customers 110A-N. For example,an SLA of the customer 110A may include a price offering of $400, and anSLA of the customer 110C may include price offering of $600 fordeploying same cloud service in the computing cloud 100.

The differentiated pricing module 208 may calculate or estimatedifferent price offerings for each of the customers 110A-N. Thedifferentiated pricing module 208 is further configured to determineprice offerings for each of the requests based on past distribution ofdemand after observing the current demand of the customers 110A-N andthe prior distribution of resources for deploying the requested one ormore services to these customers 110A-N. Further, differentiated pricingmodule 208 is configured to generate a low price for the one or morecloud services if a performance level entered by each of the customers110A-N is low.

The recommender system 210 is configured to recommend the generatedcloud configurations and the SLAs through the multiple output interfaces212A-N to the customers 110A-N. Further, the price offering in the SLAsmay be provided as a range, including an upper limit and a lower limitfor deploying the one or more cloud services. The recommender system 210is configured to search for an enhanced, improved, and in some casesoptimal or best cloud configuration for each of the requests, based onat least one of the prioritization of requests, a class of each of thecustomers 110A-N, past behavior of each of the customer 110A-N, and acurrent demand of the one or more cloud services in the cloud 100. Therecommender system 210 can be further configured to assign a priority tothe one or more cloud services, such that a cloud service with highestprobability of acceptance is given higher preference to receive orallocate the resources.

Further, each of the output interfaces 212A-N may include one or morebuttons having at least one of a deploy button and a cancel button. Eachof the customers 110A-N may initiate a negotiation of the SLA byselecting the cancel button if the customer 110 is not satisfied withthe recommended SLA (or cloud configuration). The SLA negotiator 214 isconfigured to allow each of the customers 110A-N to negotiate terms ofits associated SLA. The cloud 100 may provide the one or more cloudservices based on the negotiated multiple SLAs to each of the customers110A-N. The SLA negotiator 214 is further configured to perform thesteps of receiving, generating and recommending until the customer 110is satisfied with the SLA. Each of the customers 110A-N may negotiatethe terms of its associated SLA based on a trade-off between the one ormore high-level parameters at a service layer of the cloud 100. The SLAnegotiator 214 is further configured to change the terms of the SLAbased on the service level SLA negotiation. In an embodiment, the cloudconfiguration generator 206 may modify the SLA based on the receivedinputs from the customers 110A-N.

FIG. 3 shows an exemplary screenshot 300 of the SLA regulation system108 for configuring the SLA regulation system, in accordance with anembodiment of the present disclosure. As discussed with reference toFIG. 2, the SLA regulation system 108 includes multiple service inputinterfaces 202A-N. The customers 110A-N can interact with the serviceinput interface 202. The service input interface 202 may include one ormore fields 302A-N, in which the customers 110A-N may input one or morehigh-level parameters or service inputs. The screenshot 300 may furtherinclude the structural components 204-216 of the SLA regulation system108 (not shown in FIG. 3) operating in the background/at a backend. Thescreenshot 300 may receive more than one request for cloud services frommultiple customers 110A-N at a time. Further, the one or more requestsmay be for the same cloud services or resources. As shown, each of theservice input interfaces 202A-N may include one or more buttons 308A-Nthrough which the customer 110 may submit the details to the SLAregulation system 108. The buttons 308A-N may include, but are notlimited to, a ‘Clear Form’ button, a ‘Fine Tune Preference’ button, a‘View Configuration’ button, a ‘Compare to other Vendors Button’ button,an ‘Order and Deploy’ button, and so forth. It may not be necessary forthe customer 110 to enter low-level details about the cloudconfiguration, such as hardware, platform, number of CPUs, number ofvirtual machines, etc., and instead the customer may only enterservice-specific parameters like Green Point value, performance level,budget, and so forth. The SLA regulation system 108 can automaticallygenerate and recommend a cloud configuration and SLA to multiplecustomers 110A-N based on one or more high-level configuration detailsreceived from multiple customers 110A-N.

At the back-end (as shown in FIG. 3), the SLA regulation system 108 maytake the user preferences (e.g., usage level, load level, cost (budget),performance, and Green Point) as input and search for the bestconfiguration that is closest to user preferences and then outputs thecloud configuration and the corresponding SLA through the outputinterfaces 212A-N. In an embodiment, the cloud configuration generator206 can generate the cloud configurations along with the SLArecommendations based on a demand of the customers 110A-N for servicedelivery, availability and dependency of hardware and software in thecloud 100. The recommender system 210 of the SLA regulation system 108may plan the cloud configurations and SLAs for the requested servicesfor different customers 110A-N based on the high-level parameters asinput by these customers 110A-N. The recommender system 210 may alsorecommend the generated cloud configurations and the SLAs to multiplecustomers 110A-N through the output interfaces 212A-N. The recommendersystem 210 may determine probability of deployment corresponding to thebudget to be offered for all the requests. As shown, the differentiatedpricing module 208 may perform discounting in price offerings based onGreen operations (304). The SLA regulation system 108 (or recommendersystem 210) can effectively search for an enhanced, improved, or evenbest configuration from available resources for multiple requestsreceived from the multiple customers 110A-N based on the probability ofdeployment, current demand of resources, and so forth. The recommendersystem 210 runs at a backend of the snapshot 300. Further, the customer110 may select the “View Configuration” button 308C to view the samplecloud configuration and SLA. The customer 110 may negotiate or fine-tunethe sample cloud configuration or the SLA by selecting the ‘Fine TuneConfiguration’ button 308B. The SLA regulation system 108 may regulatethe recommendations based on customer type and behavior based ondynamics of a synchronous or substantially synchronous cloudenvironment, and accordingly offers price offering as a range tocustomers 110A-N.

The SLA regulation system 108 includes the SLA negotiator 214 thatallows the customers 110A-N to negotiate and to regulate the SLArecommendations based on their budget as well as correspondingenergy-performance trade-offs. In one embodiment, the SLA regulationsystem 108 implements a game-theoretic approach to offer differentiatedprice ranges to different customers 110A-N depending on the type andbehavior of the customers 110A-N. The differentiated pricing module 208may enhance, increase or even maximize revenue through a game theoreticapproach between customers 110A-N and the service provider. Thedifferentiated pricing module 208 may design a pricing based game(explained in detail in FIGS. 8A-8C) between the customers 110A-N andthe service provider(s) in such a way that the revenue of the serviceprovider(s) is enhanced, increased, or even maximized, while enhancing,improving, or even ensuring customer satisfaction,quality-of-recommendation, and/or allowing customers 110A-N to trade-offbetween budget, performance, and energy-efficiency. After negotiating,each of the customers 110A-N may order and deploy the cloud services byselecting the ‘Order and Deploy’ button 308N.

FIG. 4 illustrates an exemplary embodiment (block diagram 400) of theSLA regulation system 108 receiving one or more inputs from multiplecustomers 110A-N. The SLA regulation system 108 may take servicepreference inputs via service input interfaces 402A-N from the multiplecustomers 110A-N. Further, the SLA regulation system 108 may process theinputs received from multiple customers 110A-N and generate theircorresponding recommendations, such as price offerings 404A-N and cloudconfigurations or SLAs 406A-N, respectively. The customers 110A-N may bespatially separated. For example, customer A may be present in Sydney,Australia, while customer N may be present in San Francisco, USA.

FIG. 5 illustrates an exemplary embodiment of a system architecture 500for the SLA regulation system 108 to handle multiple requests, inaccordance with an embodiment of the present disclosure. As discussedwith reference to FIGS. 1 and 4, the SLA regulation system 108 mayreceive one or more inputs 402A-N from the customers 110A-N forrequesting one or more services from the service providers in the cloud100. As shown, the SLA regulation system 108 may use one or moremechanisms and information stored in the database 216 to generate priceofferings 404A-N and cloud configurations or SLAs 406A-N for multiplecustomers 110A-N. The SLA regulation system 108 may use information,such as customer priority 502, deployment probability distribution 504,and differentiated pricing mechanisms for price range offerings from thedatabase 216 to generate SLAs for multiple customers 110A-N. Each of thecustomers 110A-N may register with the service provider to access one ormore cloud services. Further, the customers 110A-N may be classifiedinto one or more classes such as, but not limited to, a gold class, asilver class, and a bronze class. In an embodiment, the customerpriority can be input by the customers 110A-N during registration, orcan also be learned by the recommender system 210 based on pastactivities of the customers 110A-N. Further, the request processor 204may process the one or more requests received from the customers 110A-N,and may prioritize them based on customer information and determinecustomer priority information 502. Further, the recommender system 210may determine, for each of the requests, a probability of deployment 504of the one or more services corresponding to the price offering.

The recommender system 210 is further configured to assign a priority tothe one or more cloud services, such that a cloud service with highestprobability of acceptance is given higher preference to get theresources. Further, the recommender system 210 may determinerecommendation acceptance probability distribution by monitoring theacceptance of the cloud configuration or the recommended SLA by thecustomers 110A-N over a period of time.

In an embodiment, the differentiated pricing module 208 may determine adifferentiated price offering (or budget offering) 506 for each of therequests (customers 110A-N) based on a past distribution of demand afterobserving the customers' current demand and the prior distribution ofresources for deploying the requested one or more services to thesecustomers 110A-N. The differentiated pricing module 208 may furthergenerate a low price for the one or more cloud services if a performancelevel entered by a customer of the customer 110A-N is low.

FIG. 6 illustrates an exemplary screenshot 600 of the SLA regulationsystem 108, in accordance with an embodiment of the present disclosure.As discussed with reference to FIGS. 1-2, the request processor 204 mayreceive and process requests received from the multiple customers110A-N. The SLA regulation system 108 may generate cloud configurationsand SLAs for different customers 110A-N. Further, the SLAs for differentcustomers 110A-N may include different price offerings, as determined orcalculated by the differentiated pricing module 208 based on one or morefactors, such as past behavior and class of the customers 110A-N.

FIG. 7 is a flowchart illustrating various steps of a method 700 forregulating service level agreements (SLAs) by the SLA regulation system108, in accordance with an embodiment of the present disclosure. Asdiscussed with reference to FIG. 2, the SLA regulation system 108includes one or more service input interfaces 202A-N, the requestprocessor 204, the cloud configuration generator 206, the differentiatedpricing module 208, the recommender system 210, the one or more outputinterfaces 212A-N, the SLA negotiator 214, and the database 216. Asdiscussed with reference to FIG. 1, the customers 110A-N may request oneor more cloud services in the cloud 100 via the service input interfaces202A-N.

At step 702, differentiated pricing to offer as a service budget to thecustomers 110A-N may be calculated by the differentiated pricing module208. The differentiated pricing may be calculated based on thedeployment probability distribution 712A, as explained with regard toFIG. 2. In an embodiment, the differentiated pricing module 208 may useany related art or later developed algorithm to calculate the priceoffering for different customers 110A-N. In some embodiments, thedifferentiated price offering may be presented to the customers 110A-Nthrough the output interfaces 212A-N at step 712.

At step 704, for all received requests, probability of deployment at acorresponding price offering (i.e. sample price offering) is determined.In an embodiment, the recommender system 210 may determine theprobability of deployment. At step 706, the requests may be prioritizedand put in a queue based on a descending order of probability ofdeployment and price. In an embodiment, the request processor 204 mayprioritize the requests. At step 708, for each of the requests in thequeue, the availability of resources may be reduced in the computingcloud 100 based on an expected resource demand of all previous requestsin the queue. As discussed with reference to FIGS. 1-2, the database 216may store the details about the resources and their availability in thecloud 100. In an embodiment, the request processor 204 may reduce theavailability of resources for each of the requests in the queue and mayuse information such as, deployment probability distribution, customerpriority, customer preferences (or high-level parameter inputs), andresource availability information.

Then, at step 710, an enhanced or best configuration for each of thecustomers 110A-N may be searched. The enhanced or best configuration foreach of the customers 110A-N may include cloud configuration, priceoffering, and SLA. In an embodiment, the enhanced or best configurationmay be searched by the SLA regulation system 108 using information suchas resource availability information, budget, performance and energyestimations. Further, in an embodiment, steps 704 to 710 may beperformed by the recommender system 210.

FIGS. 8A-8C illustrate a method 800 for providing one or more cloudservices to a number of customers 110A-N in the cloud architecture 100,in accordance with various embodiments of the present disclosure. Asdiscussed with regard to FIGS. 1-2, the SLA regulation system 108 mayreceive and process requests for various cloud services received fromthe customers 110A-N simultaneously or substantially simultaneously.Further, the SLA regulation system 108 is configured to generate cloudconfigurations and regulate and SLAs for the customers 110A-N.

At step 802, the customers 110A-N may enter one or more high-levelparameters or service inputs in their respective service inputinterfaces 202A-N. At step 804, one or more requests for the one or morecloud services may be received by the request processor 204 of the SLAregulation system 108 simultaneously or substantially simultaneously.The customers 110A-N may be classified or categorized into multipleclasses based on predefined criteria. At step 806, differentiated priceofferings for all the customers may be determined based on a pastdistribution of demand after observing the customers' current demand andthe prior distribution of resources for deploying the requested one ormore services to these customers 110A-N. In an embodiment, thedifferentiated pricing module 208 may determine the price offerings fordifferent customers 110A-N. At step 808, a probability of deployment ofthe one or more services at an offered or corresponding price offeringmay be determined by the recommender system 210.

At step 810, the request processor 204 may process the requests andprioritize the requests based on the probability distribution ofactually deploying a requested service, a budget of each of thecustomers 110A-N, and an expected demand of the requested service basedon the probability distribution. At step 812, the requests may beprioritized in a queue based on a descending order of the probability ofdeployment and price offering (a sample price).

At step 814, an availability of resources may be reduced for each of therequests based on an expected demand of the one or more cloud servicesby previous requests in the queue. In an embodiment, the requestprocessor 204 may reduce the availability of the resources whileprocessing the previous requests in the queue. At step 816, a number ofcloud configurations along with the SLAs may be generated for each ofthe customers 110A-N based on the prioritization of the requests, aclass of each of the customers 110A-N, past behavior of the customers110A-N, and a current demand of the cloud services in the computingcloud 100. In an embodiment, the cloud configuration generator 206 maygenerate the cloud configurations and the SLAs. In another embodiment,the recommender system 210 may generate the cloud configurations andSLAs.

At step 818, an enhanced, optimal or best cloud configuration and anenhanced, optimal or best SLA for each of the customers 110A-N may besearched. In an embodiment, the recommender system 210 may search forthe enhanced or best configuration and the SLA. Then, at step 820, thegenerated cloud configurations and SLAs may be recommended to thecustomers 110A-N. In an embodiment, the recommender system 210 canrecommend the cloud configurations and SLAs to the customers 110A-N. Atstep 822, each of the customers 110A-N may be allowed to negotiate oneor more terms of the SLA(s). In an embodiment, the customers 110A-N maynegotiate the terms of the SLAs via the SLA negotiator 214, if they arenot satisfied with the recommended SLAs. Thereafter, at step 824, it ischecked whether or not any selection from the customers 110A-N isreceived. In case one or more customers 110A-N have not provided anyselections or inputs for negotiations, then step 832 is executed. Atstep 832, it is checked whether the customer is satisfied or not, thenstep 834 may be performed. At step 834, the cloud 100 may provide thecloud services according to the SLA.

If at step 824, selection(s) or input(s) is received from one or more ofthe customers 110A-N, then step 826 may be performed. At step 826, oneor more high-level inputs may be received from the customers 110A-N.Then, at step 828, cloud configuration(s) and the SLA(s) may be modifiedbased on the selection information or the inputs received from thecustomers 110A-N. At step 830, the cloud configuration(s) and the SLA(s)may be displayed or presented to the customers 110A-N via the one ormore output interfaces 212A-N. Thereafter, steps 832 and 834 areexecuted as explained above.

Exemplary Equations and Calculations

Embodiments of the present disclosure include a method for calculatingor estimating differentiated price offerings of cloud services fordifferent customers 110A-N. The disclosed method for calculating priceofferings is based on a pricing based game mechanism. The followingexemplary assumptions and notations are used to explain the pricingbased game mechanism.

Exemplary Notations Used for Calculating Differentiated Price Offeringsfor Multiple Customers

The disclosed methods and systems for calculating differentiated pricingand providing cloud services may use many equations and short notationsas explained in subsequent sections. ‘K’ may refer to Total number oflevels for performance. ‘pg’ may refer to Price for Gold Customer atfull performance (at K). ‘ps’ may refer to Price for Silver Customer atfull performance (at K). ‘pb’ may refer to ‘Price for Bronze Customer atfull performance (at K)’. ‘D(p,l)’ may refer to ‘Discounted price atperformance level ‘l’ given price ‘p″. Discount may be given for highgreen points or less performance, i.e. less computing resources.‘Pric(p,l)’ may refer to ‘Probability that the Customer i in class ‘c’accepts price ‘p’ at level ‘l″. ‘q’ may refer to ‘Total demand forresources’. ‘ng’ may refer to ‘Total number of Gold customers’. ‘ns’ mayrefer to ‘Total number of Silver customers’. ‘nb’ may refer to ‘Totalnumber of Bronze customers’. ‘n’ may refer to ‘Total number ofcustomers. (n=ng+nb+ns)’. ‘C(q)’ may refer to ‘Total cost incurred toavail ‘q’ resources'.

Exemplary Assumptions for Calculating the Differentiated Price Offeringsfor Multiple Customers

One assumption is that there are three categories/classes of customers,namely gold class, silver class, and bronze class. This disclosedpricing based game mechanism can be easily generalized to any number ofdifferentiated classes of customers 110A-N without any limitations.Another assumption is that there is a one to one correspondence betweenthe Green Points and the performance level(s) at which the customer 110decides to operate. For example, if the required performance level ishigher, then the Green Point level can be lower. A further assumption isthat the customers 110A-N may be selfish and rational, but myopic. Inother words, the customers 110A-N may always try to enhance, improve, ormaximize their benefits in the current period. As discussed withreference to FIG. 2, the recommender system 210 is configured to learnabout customer's (110A-N) behavior and store the information in thedatabase 216. The recommender system 210 may further determine orprovide probability distributions for a customer's behavior from hispast actions.

In an embodiment, the SLA regulation system 108 may include anintelligent agent (not shown) in game theoretic settings that may chooseactions that are not most profitable to the customer 110 in the currentperiod, but the intelligent agent can mislead the recommender system 210in such a way that in the future, the recommender system 210 may have alow price offering for this customer 110. Another assumption is that thecustomers 110A-N may value future profits much less as compared tocurrent profits. A single customer (e.g., 110B) may not be able tomanipulate prices, and even if the customer 1108 is able to accomplishthis, he/she may find it difficult to perform the manipulation toachieve a useful result.

Another assumption is that price may be lower if performance requirementis lower. This reduction in price is captured by function D(p,l). HereD(p,l) refers to discounted price at performance level ‘I’ given price‘p’. Similarly, there may be a discount for high green points or lessperformance, i.e. less computing resources. For example, in thedisclosed SLA regulation system 108, lower performance mostly leads tohigher Green Point, or conversely, if the customer 110 desires to pursuegreener deployment, then the performance level may be reduced. This mayin turn lead to discounts to the customers 110A-N. Here, D(p,l) canrefer to the discounted price that the customer 110 may have to pay ifthe customer 110 chooses to operate at performance level I, whereas p isthe price at performance level K. Further, in some embodiments, othermethods or functions may be used to determine the discount. In anembodiment, a simple and general approximation of the discount functioncan be alinear relationship with the performance level and may bedenoted as “D(p,l)=(I/K)* p”.

The recommender system 210 may keep track of behavior of customers110A-N in each round or negotiation iteration. The recommender system210 can continue learning probabilities about behavior of each of thecustomers 110A-N. That is, what is the probability of a customer (of thecustomers 110A-N) selecting a given performance level at the given priceoffering. Further, depending on the discounting model, the disclosedmechanism determines the price offering for enhanced, improved or even amaximum performance level as the upper-limit of the price range offered.The discounting model (e.g. “D(p,l)=(I/K)*p”) can then be used tocompute the price of a lower or the lowest performance level as thelower limit of the range.

Exemplary Method for Calculating Differentiated Price Offering forMultiple Customers

The exemplary goal or advantage of the SLA regulation system 108 is tomaximize profit for the service provider. There is a difference betweenrevenue and the cost. The pricing of a single object is performed as“Max pd(p)−C(d(p))”, here D(p) is demand at price ‘p’. For explainingthe method, a static pricing scheme is used, but a person skilled in theart will appreciate that the pricing scheme can be dynamic. Therefore,according to the static pricing scheme, the customers 110A-N may beoffered or may view the same price in the SLA. The customers 110A-N areclassified into multiple classes. Further, the price is kept dynamic forcalculation purposes only. The resources required for deploying servicescan be computing servers in the cloud 100. The resources may not be soldforever, but rather rented out for specified duration to variouscustomers 110A-N. Therefore, based on dynamic demand, the resources inthe cloud 100 may be priced. Also, the differentiated pricing module 208may implement the pricing based game such that a discount may beprovided to customers requesting less resources (e.g. going more green).Thus, for the SLA regulation system 108, d(p) at level I may refer toexpected number of customer (of the customers 110A-N) that accept the(I,p) configuration.

The d(p) may be calculated based on probability distribution Pric (i.e.using prior distribution) and the performance requirement set by thecustomer 110 at period ‘t’. Therefore, q refers to an expected number ofresources required given a current required configuration.

The disclosed method may use either of two of the following approaches.In a first approach, the differentiated pricing module 208 may determinethe resource price based on current demand of the resource (withoutconsidering the uncertainty in change of demand based on user'slikelihood of actually renting the resources). In a second approach, thedifferentiated pricing module 208 may determine the resource price basedon expected demand (using prior distribution without considering thecurrent demand). Further, the differentiated pricing module 208 isconfigured to determine price offerings based on past distribution ondemand after observing the customers' current demand and the priordistribution. The differentiated pricing module 208 may use priordistribution on demands and current demand in pricing, to determine andcalculate price offerings and suggest some configurations to thecustomers 110A-N. In an exemplary scenario, some customers (of thecustomers 110A-N) may drop off as they may not like the suggestedconfiguration or may be for other reasons. In such a situation, theresources in the cloud 100 may be underutilized. In another exemplaryscenario, some customers (of the customers 110A-N) may increase theirrequirement on performance levels and the resources in the cloud 100 mayget overloaded. To minimize or avoid such extreme cases, the disclosedsystem and method for providing cloud services may use a customerbehavior model, which can be used to calculate the probability of acustomer 110 or customers 110A-N accepting a certain configuration froma history and current demand of the customers 110A-N. The system ormethod may calculate value of q by using such behavior based models anddistributions as follows:

$q = {{\sum\limits_{\{{i = 1}\}}^{\{{i = {ng}}\}}{\sum\limits_{\{{l = 1}\}}^{\{{i = k}\}} {*{\Pr_{i}^{g}( {{D( {p_{g},l} )},l} }{current}\mspace{14mu} {demand}} )}} + {\sum\limits_{\{{i = 1}\}}^{\{{i = {ns}}\}}{\sum\limits_{\{{l = 1}\}}^{\{{i = k}\}} {*{\Pr_{i}^{s}( {D( {p_{s},l} )} }{current}\mspace{14mu} {demand}} )}} + {\sum\limits_{\{{i = 1}\}}^{\{{i = {nb}}\}}{\sum\limits_{\{{l = 1}\}}^{\{{i = k}\}} {*{\Pr_{i}^{b}( {{D( {p_{b},l} )},l} }{current}\mspace{14mu} {demand}} )}}}$

Exemplary Calculation of Expected Demand (First Approach)

One exemplary method of calculating differentiated price offering may bedemonstrated by following example. In one example, there are only goldcustomers and a price of $10 is set for full performance, where fullperformance K=3. (Low, medium and High). Further, a linear discountfunction i.e. “D(p,l)=(I/k)*p” may be used in this embodiment. Thus,D(10,1)=$3.33, D(10,2)=$5 and D(10,3)=$10. In this example, there aretwo customers 110A-B who have set their demands to be High and Medium,respectively. Under that demand the service deployment probabilities forthe customers 110A-B may be assumed to be as follows (these values canbe determined based on past behavior pattern with an initial assumptionof uniform distribution).

For customer 110A; Pr_(—)1(3.33,1|(high demand)=0.2 (that is acceptinglow performance at $3.33, if he/she has demanded initially for highperformance);

Pr_(—)1(5,2|high demand)=0.4; Pr_(—)1(10,3|high demand)=0.15; 25% of thetime the customer 110A may reject the configurations and leave thesystem.

For customer 110B: Pr_(—)2(3.33,1|medium demand)=0.1 (that is acceptinglow performance at $3.33, if he has demanded initially mediumperformance); Pr_(—)2(5,2|mediumdemand)=0.6;Pr_(—)2(10,3|mediumdemand)=0.2; 10% of the time customer 110B may rejectthe configurations and leave the system.

In some embodiments, various monitoring and statistics techniques may beused to determine prior distributions on customers 110A-N who can acceptcertain configurations and calculate the posterior after they are set.Based on the above information, the expected demand ‘q’ can becalculated as

q=1*0.2+2*0.4+3*0.15+1*0.1+2*0.6+3*0.2=3.35

Exemplary Equations and Calculations for Maximizing Revenue of theService Provider

${Maximize} = {{\sum\limits_{\{{l = 0}\}}^{\{{i = K}\}}( {\sum\limits_{\{{i = 1}\}}^{\{{i = {ng}}\}}{{D( {p_{g},1} )}{\Pr_{i}^{g}( {{D( {p_{g},1} )}, 1 \middle| {{current}\mspace{14mu} {demand}} } )}}} )} + ( {{\sum\limits_{\{{i = 1}\}}^{\{{i = {ns}}\}}{{D( {p_{s},1} )}( {\Pr_{i}^{s}( {{D( {p_{s},1} )}, 1 \middle| {{current}\mspace{14mu} {demand}} } )} )}} + {\sum\limits_{\{{i = 1}\}}^{\{{i = {nb}}\}}( {{{D( {p_{b},1} )}( {\Pr_{i}^{b}( {{D( {p_{b},1} )}, 1 \middle| {{current}\mspace{14mu} {demand}} } )} )} - {{C(q)}(1)}} }} }$

At time ‘t,’ the customers 110A-N may log into the disclosed SLAregulation system, as explained with regard to FIG. 1, and select theirpreferred performance level (or green point level). The SLA regulationsystem 108 can solve the above pricing problem, as well as recommendeach of the customers 110A-N some configurations that is tuple, (GreenPoint Levels, Performance Level and Price). The pricing scheme may befixed for a certain duration initially. The customer 110 may accept theconfiguration or may modify performance level or green point level (orother high-level parameters). Accordingly, the SLA regulation system 108may modify the SLA or price, and display to the customer 110. Thecustomer 110 may continue playing, and finally within some period he/shemay either accept some configuration or reject and quit. After all ‘n’iterations, based on whether the customers' requests are accepted orrejected, the price offerings may change in the next iteration.

Exemplary Cost Estimations

The disclosed method or system implements a proper cost estimation tohave a good solution on the offered price to customers 110A-N. In anembodiment, a conservative approach toward cost estimation of expecteddemand may be to use worst-case cost from the available resources.However, this approach may lead to high cost estimations, and hence highprice offering and potentially reducing the probability of deployment(depending on distribution). Another extreme approach can be to use bestcase cost estimations from available resources. However, this would leadto lower prices for services and potential loss of revenue. An averagecost estimate from the available resources can be used. However, a moresophisticated cost estimation can be performed through properexperimentation and reach a point where the price does not become toohigh or too low.

A method for optimizing the estimation of discounts and cost isexplained using the following example. In this example, Yg constitutes adiscount for Gold customers over Silver and Ys for Silver customers overBronze (i.e., pg=Yg and ps=Ys). By choosing pb, all of the other pricescan be derived. It may be assumed that pb is always between some pbl andpbu. The upper limit, pbu, can be some number higher than the cost ofall available resources. The lower limit, pbl, can be the cost of asingle cheapest resource available. Initially pbl may be used andgradually increased until pbu and ‘q’ (expected demand given currentdemand) and profit may be determined. In this example, pb=the price thatmaximizes (or enhanced/improves) the above term. The algorithm to setprices (assuming to be the step size) is explained in the followingsection. Further, the algorithm takes a value of pbl, pbu, A, prci,D(p,l), Yg, Ys as input and outputs value of pb, ps, pg. Steps of thealgorithm may include:

Step 1. p′_(b) = p_(bi) Step 2. max =0 Step 3. p′_(s) = y^(s) * p′_(b)and p′_(g) = y^(g) * p′_(s) Step 4. Find q at price p′_(b,) p′_(s,)p′_(g) Step 5. Calculate current profit as given by expression 1 Step 6.If current profit > max, then p_(b) = p′_(b) and max = current profitStep 7. p′_(b) = p′_(b) + Δ Step 8. If p′_(b) <= p_(bh) GOTO Step 3 Step9. Out : p_(b), p_(s) = y^(s) p_(b), p_(g) = y^(g) p_(s)

Even though the above disclosure assumes that Gold customers getmaximize (or enhanced/improved) discounts and Silver customers also getdiscounts, the disclosed methodology can also be used wherein the pricefor Gold customers is highest and highest priority may be given to themwhile suggesting configurations. The prices pb, ps, and pg are the upperlimit of the price range offered (corresponding to the enhanced,improved or maximum performance level). The discounting function D(p,l)can be applied to these values to compute the lower limit of the pricerange (that correspond to the lowest performance level).

It will be understood that the modules and the databases referred to inthe previous sections are not necessarily utilized together in a singleform processing system. Rather, these modules are merely exemplary ofthe various modules that may be implemented within a cloud configurationsystem. Further, it will be understood that the cloud configurationsystem may include more modules than the ones described in thisdisclosure without departing from the scope of the present disclosure.

It will be appreciated that several of the above-disclosed and otherfeatures and functions, or alternatives thereof, may be desirablycombined into many other different systems or applications. Variouspresently unforeseen or unanticipated alternatives, modifications,variations, or improvements therein may subsequently be made by thoseskilled in the art, which are also intended to be encompassed by thefollowing claims.

What is claimed is:
 1. A method for providing one or more cloud servicesto a plurality of customers that are categorized into one or morecategories in a computing cloud, the method comprising: receiving aplurality of requests for requesting one or more cloud services from theplurality of customers simultaneously or substantially simultaneously,wherein the plurality of customers are categorized into one or moreclasses; prioritizing the plurality of requests based on at least one ofa probability distribution of actually deploying a requested service, abudget of each of the plurality of customers, and an expected demand ofthe requested service based on the probability distribution; generatinga plurality of cloud configurations along with a plurality of ServiceLevel Agreements (SLAs) that include differentiated price offering foreach of the plurality of customers based on at least one of theprioritization of the requests, the class of each of the plurality ofcustomers, past behavior of each of the plurality of customers, and acurrent demand of the cloud services in the computing cloud, the SLA foreach of the plurality of customers being generated to enhance at leastone of service provider revenue, customer satisfaction and quality ofrecommendation; recommending the generated cloud configurations and theSLAs to each of the plurality of customers, wherein the price offeringin the SLA is provided as a range including an upper limit and a lowerlimit for deploying the one or more cloud services such that each of theplurality of customers can negotiate terms of its associated SLA; andproviding the one or more cloud services based on the negotiated SLAs tothe plurality of customers.
 2. The method of claim 1, wherein each ofthe plurality of customers may request the one or more services byentering one or more high-level parameters through a service inputinterface including one or more input fields, wherein the high-levelparameters includes at least one of a performance level, Green Point,budget, and location.
 3. The method of claim 2, wherein each of theplurality of customers selects the high-level parameters from a valueset associated with one or more high-level parameter fields of each ofthe plurality of service input interfaces.
 4. The method of claim 3,wherein allowing each of the plurality of customers to negotiate theterms of the SLA further includes receiving, generating and recommendinguntil the customer is satisfied with the SLA, wherein each of theplurality of customers negotiates the terms of the SLA based on atrade-off between the one or more high-level parameters at a servicelayer of the cloud.
 5. The method of claim 4, further comprisingmodifying the SLAs of the plurality of customers based on the servicelevel SLA negotiation.
 6. The method of claim 5, further comprisingdetermining, for each of the plurality of requests, a probability ofdeployment of the one or more services corresponding to the priceoffering.
 7. The method of claim 6, wherein the plurality of requests isprioritized in a queue based on a descending order of the probability ofdeployment of the requested one or more cloud services and the priceoffering.
 8. The method of claim 7, further comprising reducing, foreach of the plurality of requests, an availability of resource(s) basedon an expected demand of the one or more cloud services by previousrequests in the queue.
 9. The method of claim 8, further comprisingsearching for an enhanced cloud configuration for each of the pluralityof requests based on at least one of the prioritization of requests, aclass of each of the customers, past behavior of each customer, and acurrent demand of the one or more cloud services in the computing cloud.10. The method of claim 9, further comprising determining a priceoffering for each of the plurality of requests based on a posteriordistribution of demand after observing the customers' current demand andthe prior distribution of resources for deploying the requested one ormore services to the plurality of customers.
 11. The method of claim 10,wherein the price offering in the generated SLA is provided such that apotential revenue for the service provider is enhanced while taking intoaccount the probability distribution of the customer actually deployingthe services with one or more of the high-level parameters.
 12. Themethod of claim 11, wherein the cloud configuration and the SLA arerecommended to each of the plurality of customers based on an expectedavailability of resources required for deploying the requested one ormore cloud services in the computing cloud.
 13. The method of claim 12,wherein generating the recommendation further includes assigning apriority to the one or more services, such that a service with highestprobability of acceptance is given a higher preference to get theresources.
 14. The method of claim 13, wherein the price for the one ormore cloud services is low if a performance level entered by a customerof the plurality of customers is low.
 15. The method of claim 14,wherein generating the cloud configuration along with the SLA furtherincludes: estimating at least one of a budget, a Green Point, aperformance level, and energy consumption for each possible cloudconfiguration based on the received high-level parameters.
 16. Themethod of claim 1, wherein allowing to negotiate the terms of the SLAfurther includes at least one of deploying and cancelling terms of theSLA by the customer by selecting one or more buttons of an outputinterface.
 17. A system for providing one or more cloud services to aplurality of customers in a computing cloud, the system comprising: aservice level agreement regulation (SLA) system at a service layer ofthe computing cloud, the SLA regulation system including: a requestprocessor configured to: receive a plurality of requests for requestingthe one or more cloud services from the plurality of customerssimultaneously or substantially simultaneously; and process theplurality of requests based on at least one of a probabilitydistribution of actually deploying a requested service, a budget of eachof the plurality of customers, and an expected demand of the requestedservice based on the probability distribution; a cloud configurationgenerator configured to generate a plurality of cloud configurationsalong with a plurality of service level agreements (SLAs) that includedifferentiated price offerings for each of the plurality customers basedon at least one of the prioritization of the requests, a class of eachcustomer, past behavior of each of the plurality of customers, and acurrent demand of the cloud services in the computing cloud, the SLA foreach of the plurality of customers being generated to enhance at leastone of service provider revenue, customer satisfaction and quality ofrecommendation; a recommender system configured to recommend thegenerated cloud configurations and the SLAs through a plurality ofoutput interfaces, wherein the price offering in the SLA is provided asa range including an upper limit and a lower limit for deploying the oneor more cloud services; and an SLA negotiator configured to allow eachof the customers to negotiate terms of its associated SLA, wherein thecomputing cloud provides the one or more cloud services based on thenegotiated plurality of SLAs to the plurality customers.
 18. The systemof claim 17, further comprising a plurality of service input interfacesfor receiving one or more high-level parameters through one or moreinput fields, wherein the high-level parameters include at least one ofa performance level, Green Point, budget, and location.
 19. The systemof claim 18, wherein each of the plurality of service input interfacesalso allows the customers to enter one or more service inputs, whereinthe service inputs include at least one of a service name and one ormore service specific parameters.
 20. The system of claim 19, whereineach of the plurality of customers selects the high-level parametersfrom a value set associated with one or more high-level parameter fieldsof each of the plurality of service input interfaces.
 21. The system ofclaim 20, further comprising a differentiated pricing module configuredto determine price offering for each of the plurality of requests basedon a posterior distribution of demand after observing the customers'current demand and the prior distribution of resources for deploying therequested one or more services to the plurality of customers.
 22. Thesystem of claim 21, wherein the differentiated pricing module is furtherconfigured to generate a low price for the one or more cloud services ifa performance level entered by the customer is low.
 23. The system ofclaim 22, wherein the SLA negotiator is further configured to performreceiving, generating and recommending until the customer is satisfiedwith the SLA, wherein each of the plurality of customers negotiates theterms of the SLA based on a trade-off between the one or more high-levelparameters at a service layer of the computing cloud.
 24. The system ofclaim 23, wherein the SLA negotiator is further configured to modify theSLAs of the plurality of customers based on the service level SLAnegotiation.
 25. The system of claim 24, wherein the request processoris further configured to determine, for each of the plurality ofrequests, a probability of deployment of the one or more servicescorresponding to the price offering.
 26. The system of claim 25, whereinthe request processor is configured to prioritize the plurality ofrequests in a queue based on a descending order of the probability ofthe requested one or more cloud services and the price offering.
 27. Thesystem of claim 26, wherein the request processor is further configuredto reduce, for each of the plurality of requests, an availability ofresource(s) based on an expected demand of the one or more cloudservices by previous requests in the queue.
 28. The system of claim 27,wherein the recommender system is further configured to search for anenhanced cloud configuration for each of the plurality of requests basedon at least one of the prioritization of requests, a class of each ofthe customers, past behavior of each of the customers, and a currentdemand of the one or more cloud services in the computing cloud.
 29. Thesystem of claim 28, wherein the recommender system recommends the cloudconfiguration and the SLA to each of the plurality of customers based onan expected availability of resources required for deploying therequested one or more cloud services in the computing cloud.
 30. Thesystem of claim 29, wherein the recommender system is further configuredto assign a priority to the one or more cloud services, such that acloud service with a highest probability of acceptance is given a higherpreference to get the resources.
 31. The system of claim 30, wherein thecloud configuration generator is further configured to estimate at leastone of a budget, a Green Point, a performance level, and energyconsumption for each possible cloud configuration based on the receivedhigh-level parameters.
 32. The system of claim 31, wherein each of theoutput interfaces includes one or more buttons having at least one of adeploy button and a cancel button, wherein each of the customersinitiates a negotiation of the SLA by selecting the cancel button. 33.The system of claim 32, wherein the cloud further comprises a middlewarelayer and an infrastructure layer.